Measurement and test instruments are commonly employed for testing and determining performance characteristics of electronic devices systems. Initially, such instruments were stand-alone units designed for rather limited and specific applications. Within the instrument industry, a wide variety of instrument command sets were developed which required instrument users, and test program developers, to learn a new vocabulary for each instrument. Furthermore, programming an instrument is very different than operating it from the front panel. Most instrument users find it hard to figure out how to program their instrument to automate measurements using low-level commands and drivers. Part of the problem is that users often don't understand how commands interact without trying them out. This proliferation of command sets has resulted in users spending a great deal of time learning how to program instruments, made maintenance of test programs difficult, and made it difficult to upgrade test systems as new equipment became available.
In order to reduce development costs, various standard electrical and mechanical interfaces were developed for instruments and other electronic devices. With the advent of computer communication and computer control of instruments and systems of instruments, standardized signal protocols and other standardized electrical and mechanical interfaces became more prevalent. These protocols were mainly intended to set standards for digital messages sent over these interfaces.
The Standard Commands for Programmable Instrumentation (SCPI) protocol standard was developed to define a set of commands for controlling programmable test and measurement devices in instrumentation systems. An instrumentation system is a collection of test and measurement devices connected by a communication bus to a control computer called the system controller. An instrumentation system may include stand-alone devices like IEEE 488 instruments or instrument cards in an enclosure such as a VXIbus rack.
Client processes often located on remote computers may send commands (for example, a command to apply a signal, to make a measurement, to perform a calibration, or the like) to one or more instruments over an instrument bus. These commands are called program messages. Instruments may also send response messages back to the clients. The response messages may be measurement results, instrument settings, error messages, or the like. Prior to the SCPI standard, the commands that controlled a particular device function varied between instruments which had similar capabilities. SCPI provides a uniform and consistent language for the control of test and measurement instruments. The same commands and responses can control corresponding instrument functions in SCPI equipment, regardless of the supplier or the type of instrument.
For instance, the command to measure a frequency is the same using the SCPI standard, whether the measurement is made by an oscilloscope, spectrum analyzer, or a counter. The set of commands to control multi-meters from two manufacturers differs only in places where the underlying hardware has different capabilities. Thus, instruments from different vendors can be expected to be essentially interchangeable in many applications.
SCPI provides a means to perform simple operations. The MEAS (measure) command, for example, can configure and read data from an instrument. When the program message “:MEAS:VOLT:AC?” is received by a voltmeter, for example, the meter will select settings and configure its circuitry for an AC voltage measurement, initiate the measurement, and return the result to the system controller. The question mark at the end of the command instructs the voltmeter to return the measured value to the controller. As another example, the SCPI command “:MEAS:FREQ?” returns a frequency measurement from an oscilloscope, spectrum analyzer, or a counter, despite great internal differences in the hardware of the instruments.
SCPI commands are organized in hierarchical structures referred to as trees. In the above two commands, “MEAS” is a parent node in a SCPI tree while “VOLT” is one child node of that parent and “FREQ” is another child node of that parent.
A central feature of the SCPI standard is the Command Reference which is a list of definitions for all the program messages. These definitions specify precisely the syntax and semantics for every SCPI message. Instrument functions covered by the standard may only be controlled through SCPI commands. However, SCPI was designed with a modular structure that permits commands controlling new functions to be added at any time.
The Hewlett-Packard Interface Bus (HPIB) interface system, also known as the General-Purpose Interface Bus (GPIB) or by its Institute of Electrical and Electronic Engineers (IEEE) specification number IEEE 488, is a scheme by which groups of devices may be connected to a controlling computer and communicate under its direction. Instruments from multiple vendors can be operated in the same HPIB system. SCPI commands can be implemented on an instrument using any sort of interface, as for example, HPIB, serial/RS-232, VXI backplane, or the like, but they are especially common on HPIB busses.
The IEEE 488.1 standard defines hardware for an instrumentation bus. It is a digital bus with lines for the serial transfer of data bytes, plus extra control and handshaking lines. The IEEE 488.2 is an additional standard that defines protocols for data/command exchange between controller and instruments, basic data formats, systematic rules for program messages, and definition of instrument status structures. IEEE 488.2 also defines some common commands covering instrument functions that are universally applicable. However, IEEE 488.2 does not define commands or data structures for specific applications. Instrument makers are free to define the commands that control the primary functions of their instruments. SCPI builds upon IEEE 488.2 by standardizing these primary functions.
Accordingly, instrument driver routines and SCPI commands are the most common modes of remotely controlling instruments, for example to execute a test program.
However, programming instruments with either of these two technologies can be difficult. Instruments are complex, and the SCPI commands that can be used with each particular instrument depend upon the capabilities of the underlying hardware of the instrument, so it is difficult for a user to keep track of exactly which SCPI commands can be used with each particular instrument—especially when the user is programming a large number of different instruments. Also, it is often difficult to know which driver routine or SCPI command can perform a desired task, and users often don't understand how various commands interact without trying them out.
What is needed, therefore, is a tool to let users operate an instrument remotely without requiring them to know all of the commands and their associated characteristics before-hand.